Fix slugify reporter variations #5997
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…_from_reporter-discards-some-data
…_from_reporter-discards-some-data
…_from_reporter-discards-some-data
quevon24
added
skip-celery-deploy
skip-deploy
skip-cronjob-deploy
skip-daemon-deploy
and removed
skip-deploy
labels
…_from_reporter-discards-some-data
flooie
approved these changes
Jul 28, 2025
flooie
deleted the
5389-slugifying-variations-in-get_canonicals_from_reporter-discards-some-data
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Instead of solving this in get_canonicals_from_reporter(), I fixed it directly in slugify_reporter().
Why? Because slugify_reporter() is the first and central place where reporter input is normalized. By adding a final fallback check for known variations (using
VARIATIONS_ONLY), we can cleanly disambiguate most cases before they hit more complex logic later.What works now
Here are cases that now redirect correctly from the variation to the intended slug:
What still can't be disambiguated
Some abbreviations are too ambiguous to resolve safely. For example:
"B.R." is used both as a standalone reporter for Bankruptcy Reporter and as a variation for Baltimore City Reports ("Balt. C. Rep."). When we receive "B.R.", it exists in REPORTERS, so the function assumes it's the Bankruptcy Reporter and returns its slug "br". But this could be incorrect, the user might've meant "Balt. C. Rep." (slug "balt-c-rep"), which also uses "B.R." as a variation.
Because we can't safely guess the intent, we continue suggesting an alternative reporter:
Or continue showing a page with HTTP 300 like this if disambiguation is not possible:
Here's the list of cases that cannot be automatically disambiguated: